1. Field of the Invention
The present invention relates to the formation and use of secure network connections. More specifically, the present invention relates to forming secure, scaleable network connections for a plurality of network devices.
2. Description of the Related Art
Computer networks, and in particular Wide Area Networks (WANs) such as the Internet, provide opportunities for the misuse and abuse of communications traveling thereover. For example, two users communicating via the WAN may have their communications intercepted and/or altered. Also, it is possible for one user to misrepresent his or her identity to another user. As a final example, a user may utilize network resources and communications to disrupt all or part of the network.
Thus, there is a need for both privacy and authentication between users of the WAN communicating with one another. In other words, users should be able to rely on the fact that their transmissions will not be intercepted or altered, and that transmissions from someone purporting to be a particular user do in fact originate from that user.
One type of defense against ill-intentioned uses of the WAN is a device operating at the edge of a private network, such as a Gateway, Firewall or some other dedicated network appliance. Such a device operates to filter transmissions between the private network and the WAN and/or to protect the transmissions that do go through by encrypting/decrypting (i.e., encoding/decoding) those transmissions.
Other related types of defenses function by establishing the identity of a sender and/or recipient before sending/receiving a communication. Still other defenses include establishing a secure channel between two communicating devices.
A particular conventional protocol for providing security between devices operating over an Internet Protocol (IP) network is known as IPsec. Short for IP Security, IPsec is a set of protocols supporting the secure exchange of IP packets at a network layer. Two of the protocols used are the Authentication Header protocol (AH) and the Encapsulating Security Payload protocol (ESP).
AH is designed to ensure that transmitted packets are not altered during transit over the network, but does not protect the contents of the packets from being viewed by other users of the network such as intercepting parties. ESP, on the other hand, ensures the confidentiality of the packet contents. ESP provides an optional authentication mechanism; however, this mechanism is only for authenticating the data payload of the packet (and associated ESP headers/trailers). Therefore, ESP does not authenticate an IP Header of a packet indicating an original IP address on the network from which the packet originated. It is also possible to use AH and ESP in conjunction with one another, in order to achieve the advantages of both.
Whether using AH or ESP, IPsec operates in either transport or tunnel mode. Transport mode is often used in host-to-host communications; i.e., when the peer devices are the endpoints of communication. Transport mode is most useful within an overall IPsec environment including the two endpoints. Tunnel mode is typically used in communications between an IPsec-protected system and some other endpoint, such as communications sent from a private network over the Internet. In tunnel mode, the payload of a secured IP packet carries another packet containing the actual data payload to be transmitted.
A common use of the tunnel mode is to implement a Virtual Private Network (VPN). VPNs are networks that use publicly-available network resources, such as the Internet, to construct a network accessible only by selected parties. For example, a company may create its own version of a Local Area Network (LAN) using the Internet, or a worker working from a remote location may be able to utilize company resources at a company headquarters.
In order to implement the various protocols and modes of IPsec such as those discussed above, a security association (SA) is typically formed. An IPsec SA is essentially a contract or agreement between parties defining conditions according to which the two parties will communicate. For example, an IPsec SA is typically a one-way connection that defines, for example, encryption algorithms to be used during information exchange. SAs are defined by such parameters as an IP destination address and a security protocol identifier (e.g., AH or ESP). SAs typically include a security parameter index (SPI), which is a 32 bit identification number.
If an IPsec SA is considered a contract or agreement, then the terms thereof can be considered to be negotiated by a separate protocol (or manually). In other words, both communicating parties must agree on actions that will be taken on communicated packets in order to encrypt/decrypt those packets. One such protocol is known as the Internet Security Association and Key Management Protocol (ISAKMP), and one implementation of ISAKMP is known as the Internet Key Exchange (IKE).
IKE typically operates in two phases. In a first phase, parties agree as to how to protect further negotiation traffic. For example, IKE may authenticate a sender by virtue of, for example, public key encryption, also known as Diffie-Hellman encryption. In public key encryption, each user generates a public and private key, where the public key is then sent to the other party. When each user combines his own private key with the other's public key (and perhaps additional information), they each obtain an identical secret key. This secret key serves as a basis for deriving subsequent cryptographic keys.
In this way, a first user can encrypt a message using the second user's public key, and then only the second user (using his own private key) will be able to decrypt and receive the message.
Also, a first user can use his private key to sign a message and the second user, with the first user's public key, can receive and authenticate the transmitted message. Thus, the first user is authenticated to the second user as the one who sent the transmission; i.e., a “digital signature.”
This latter methodology, however, does nothing to guard against the eventuality that a third party is merely pretending to be the sender (i.e., the first user) when the keys were generated in the first place. Therefore, independent and trusted Certification Authorities (CAs) exist which issue digital certificates verifying the association of a public key with a particular user, along with other identifying information.
There are two primary modes for phase 1 of IKE: main mode and aggressive mode. Main mode, generally speaking, is a more involved but more secure method. Aggressive mode, though faster, sacrifices identity protection; however, using the public key encryption methodology just discussed obviates the need for this feature.
In a second phase, IKE negotiates the actual IPsec SA (over which the actual application layer data exchanges will take place) by setting up the encryption/authentication keys for the AH and/or ESP protocols. In particular, “quick mode” negotiates the SAs for general purpose IPsec communications. Also, it should be noted that, typically, only one phase 1 negotiation is needed for an associated plurality of phase 2 operations by a plurality of peer devices. This allows the multiple peer devices to each take advantage of the phase 1 proceedings, thereby establishing secure connections more quickly and more easily.
As shown in the above discussion, therefore, various solutions exist for implementing private and authenticated network communications. However, all of the above-discussed methodologies are conventionally implemented on a peer-to-peer and point-to-point basis. Such methodologies, unfortunately, cannot easily be extended to multicast (i.e., multi-peer to multi-peer) networking.
In other words, if each member of a group of peer devices wishes to have the capability to direct communications to each of the remaining members of the group (including simultaneously), they would have to establish SAs and IPsec tunnels between every pair of devices in the group. This number of SAs and IPsec tunnels needed to implement such a full mesh design can be described by Equation (1):
                              C          ⁡                      (                          n              ,              k                        )                          =                              n            !                                [                                          k                !                            ⁢                                                (                                      n                    -                    k                                    )                                !                                      ]                                              (        1        )            Equation (1) is a well-known combinational law, where “n” represents the number of devices participating in the group of devices, “k”=2 since only peer-to-peer connections are contemplated, and C(n,k) represents the number of connections needed. Thus, for seven devices, twenty-one peer-to-peer connections would be needed. Moreover, this number expands to forty-two SAs, since IPsec SAs are typically uni-directional and must be individually established in both directions between a given pair of peers.
Creating and managing this number of connections, which increases rapidly when even more devices are included, is impractical. In particular, creating such a large number of SAs is very costly in terms of both time and computing resources, and managing/implementing IPsec tunnels corresponding to the SAs is also difficult.
Certain conventional protocols attempt to implement a full mesh connection at a network level. For example, the Multi-Protocol Label Switching (MPLS) service provides network administrators great flexibility in managing data flow through the network by allowing the diversion of data around congestion and bottlenecks. However, such conventional mesh network structures do not, by themselves, adequately address security concerns; moreover, they are not compatible with peer-to-peer approaches such as that employed by IPsec and other security protocols.
Therefore, what is needed is a methodology for implementing a secure, private network that is easy and inexpensive to create and manage, that allows multi-casting between members, and that is easily scaleable for the purposes of increasing the number of the members.